Skip to content

feat(confirm): dedicated end state for confirmed_no_registration#23

Merged
TaprootFreak merged 3 commits into
developfrom
feat/confirm-no-registration-state
Jul 15, 2026
Merged

feat(confirm): dedicated end state for confirmed_no_registration#23
TaprootFreak merged 3 commits into
developfrom
feat/confirm-no-registration-state

Conversation

@TaprootFreak

Copy link
Copy Markdown
Contributor

Problem

The confirm API can respond 2xx with status: 'confirmed_no_registration' (introduced in DFXswiss/api#4215): the share register accepted the email, but no wallet registration matched it. The page currently renders any unrecognized 2xx status as the retryable 'unavailable' state — a permanent condition presented as a retry loop.

Changes

  • confirm-core.js: mapResult maps confirmed_no_registration → new UI state no-registration; i18n copy (de authored, en mirrored) advising to check the email used in the app or contact support. No retry CTA — the outcome is permanent.
  • confirm.js / index.html: new state-no-registration section mirroring the 'invalid' section (no CTA), wired into the page-state list and the local-preview ?mock= hook.
  • Visual matrix: confirm-no-registration (de, all three projects) and confirm-no-registration-en (desktop) views mirroring the invalid views, with baselines generated inside the pinned Playwright container (18 → 22 PNGs; existing baselines byte-identical).
  • Unit coverage: mapResult mapping; the generic i18n-parity and page-key checks cover the new keys.

Coupling

The handbook pipeline in RealUnitCH/app guards the staged web-baseline count (EXPECTED_WEB_BASELINE_COUNT). A companion PR bumps it to 22 with the matching gallery cards — merge that one together with this PR.

The confirm API can report that the share register accepted the email but
no wallet registration matched it. That is a permanent outcome; rendering
it as the retryable 'unavailable' state sent users into a retry dead-end.
New 'no-registration' state with its own copy (check the app email or
contact support, no retry CTA), mapped from the 2xx body status, plus
visual-matrix views and unit coverage.
Cover the mock loop and the real fetch-to-render seam: a 2xx body with
status confirmed_no_registration must surface the no-registration state.
@TaprootFreak

Copy link
Copy Markdown
Contributor Author

Quality gate: 2 review passes (conformance + correctness). Pass 1 findings — the mock-state loop and a missing fetch-to-render integration test for the new status — were fixed; pass 2 came back clean. Full suite ran green inside the pinned container (56 passed, 22 baselines, visual matrix check OK).

@TaprootFreak TaprootFreak marked this pull request as ready for review July 15, 2026 13:33
@TaprootFreak TaprootFreak merged commit cccba79 into develop Jul 15, 2026
2 checks passed
TaprootFreak added a commit to RealUnitCH/app that referenced this pull request Jul 15, 2026
#862)

## Why

RealUnitCH/web#23 adds a dedicated confirm-page end state
(`no-registration`) with four new Playwright baselines (18 → 22 PNGs).
The handbook deploy stages those baselines behind the
`EXPECTED_WEB_BASELINE_COUNT` guard, which requires the count bump and
the matching gallery cards in the same change.

## Changes

- `handbook.yaml`: `EXPECTED_WEB_BASELINE_COUNT` 18 → 22.
- `docs/handbook/de/index.html` (`#spec-web`): four cards for the new
views (desktop de/en, tablet, mobile), mirroring the confirm-invalid
card group.

## Coupling

Merge together with RealUnitCH/web#23 — the guard fails the next
handbook deploy if either side lands alone. The PR-level `Handbook Build
Check` does not stage web baselines, so this PR's CI is unaffected
either way.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant